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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server (http://www.etsi.org/ipr ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Access and Terminals (AT). 

The present document is part 10 of a multi-part deliverable supporting real-time multimedia services, as identified 
below: 

Parti: "General"; 

Part 2: "Architectural framework for the delivery of time critical services over cable Television networks using 
cable modems"; 

Part 3: "Audio Codec Requirements for the Provision of Bi-Directional Audio Service over Cable Television 
Networks using Cable Modems"; 

Part 4: "Network Call signalling Protocol"; 

Part 5: "Dynamic Quality of Service for the FYovision of Real Time Services over Cable Television Networks 
using Cable Modems"; 

Part 6: "Media Terminal Adapter (MTA) device provisioning"; 

Part 7: "Management Information Base (MIB) Framework"; 

Part 8: "Media Terminal Adapter (MTA) Management Information Base (MIB)"; 

Part 9: "Network Call Signalling (NCS) MIB Requirements"; 

Part 10: "Event Message Requirements for the Provision of Real Time Services over Cable Television 
Networks using Cable Modems"; 

Part 11: "Security"; 

Part 12: "Internet Signalling Transport Protocol"; 

Part 13: "Trunking Gateway Control Protocol"; 

Part 14: "Operation System Support". 

NOTE 1: The above list is complete for the first version of this Technical Specification (TS) (VI. 1.1 2001-06). 
Additional parts are being proposed and these will be added to the list in future versions". 
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The present part is part 10 of the above mentioned series of ETSI deliverables and describes the concept of Event 
Messages used to collect usage for the purposes of billing within the IPCablecom architecture. It details a transport 
protocol independent Event Message attribute TLV format, an Event Message file format, mandatory and optional 
transport protocols, the various Event Messages, lists the attributes each Event Message contains, and lists the required 
and optional Event Messages associated with each type of end-user service supported. In order to support vendor 
interoperability, implementations must minimally support RADIUS as a transport protocol. 

NOTE 2: The choice of a multi-part format for this deliverable is to facilitate maintenance and future 
enhancements. 

NOTE 3: The term MUST or MUST NOT is used as a convention in the present document part to denote an 
absolutely mandatory aspect of the specification. 



Introduction 



The cable industry in Europe and across other Global regions have already deployed broadband cable television hybrid 
fibre coax (HFC) data networks running the Cable Modem Protocol. The cable industry is in the rapid stages of 
deploying IP Voice and other time critical multimedia services over these broadband cable television networks. 

The cable industry has recognized the urgent need to develop ETSI Technical Specifications aimed at developing 
interoperable interface specifications and mechanisms for the delivery of end-to-end advanced real time IP multimedia 
time critical services over bi-directional broadband cable networks. 

IPCablecom is a set of protocols and associated element functional requirements developed to deliver 
Quality of service (QoS) enhanced secure IP multimedia time critical communications services using packetized data 
transmission technology to a consumer's home over the broadband cable television Hybrid Fibre/Coaxial (HFC) data 
network running the Cable Modem protocol. IPCablecom utilizes a network superstructure that overlays the 
two-way data-ready cable television network. While the initial service offerings in the IPCablecom product line are 
anticipated to be Packet Voice, the long-term project vision encompasses packet video and a large family of other 
packet-based services. 

The cable industry is a global market and therefore the ETSI standards are developed to align with standards either 
already developed or under development in other regions. The ETSI Specifications are consistent with the 
CableLabs/PacketCable set of specifications as published by the SCTE. An agreement has been established between 
ETSI and SCTE in the US to ensure, where appropriate, that the release of PacketCable and IPCablecom set of 
specifications are aligned and to avoid unnecessary duplication. The set of IPCablecom ETSI specifications also refers 
to ITU-SG9 draft and published recommendations relating to IP Cable Communication. 

The whole set of multi-part ETSI deliverables to which the present document belongs specify a Cable Communication 
Service for the delivery of IP Multimedia Time Critical Services over a HFC Broadband Cable Network to the 
consumers home cable telecom terminal. "IPCablecom" also refers to the ETSI working group program that shall define 
and develop these ETSI deliverables. 
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Scope 



The present document specifies IPCablecom, a set of protocols and associated element functional requirements. These 
have been developed to deliver Quality of service (QoS), enhanced secure IP multimedia time critical communication 
services, using packetized data transmission technology to a consumer's home over a cable television Hybrid 
Fibre/Coaxial (HFC) data network. 

NOTE 1 : IPCablecom set of documents utilize a network superstructure that overlays the two-way data-ready cable 
television network, e.g. as specified within ES 201 488 and ES 200 800. 

While the initial service offerings in the IPCablecom product line are anticipated to be Packet Voice and Packet Video, 
the long-term project vision encompasses a large family of packet-based services. This may require in the future, not 
only careful maintenance control, but also an extension of the present set of documents. 

NOTE 2: The present set of documents aims for global acceptance and applicability. It is therefore developed in 
alignment with standards either already existing or under development in other regions and in 
International Telecommunications Union (ITU). 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Node: layer two termination device that terminates the network end of the ITU-T Recommendation J. 1 12 
connection 

NOTE 1: It is technology specific. In ITU-T Recommendation J.l 12 annex A it is called the INA while in annex B 
it is the CMTS. 

Cable Modem: layer two termination device that terminates the customer end of the J. 1 12 connection 

Call: instance of user-initiated voice communication capabilities 

NOTE 2: In traditional telephony, a call is generally considered as the establishment of connectivity directly 

between two points: originating party and terminating party. In the IPCablecom context, as noted above, 
the communication between the parties is "connectionless" in the traditional sense. 

Event Message Attribute: predefined data element described by an attribute definition and attribute type 

Event Message: set of data, representative of an event in the IPCablecom architecture that could be indicative of usage 
of one or more billable IPCablecom capabilities 

NOTE 3: An Event Message by itself may not be fully indicative of a customer's billable activities, but an Event 
Message correlated with other Event Messages builds the basis of a billable Usage Detail Record. 

IPCablecom: ETSI working group project that includes an architecture and a series of specification that enable the 
delivery of real-time services over the cable television networks using cable modems 

IPCablecom Transaction: collection of events on the IPCablecom network when delivering a service to a subscriber 

NOTE 4: Event Messages for the same transaction are identified by one unique Billing Correlation ID (as described 
in table 32). For some services, multiple transactions may be required to provide information that is 
necessary to collect the total usage for the service. Multiple Event Messages may be required to track 
resources for each individual service used. A Transaction may persist over time. 

Service: individual or package of communications features a subscriber may select 

NOTE 5: A service is identified by a set of one or more "calls" or transactions that deliver the desired functionality 
to the subscriber. Examples of a service include: a voice communication between two local IPCablecom 
subscribers, a 3-way call, pay-per-view movie, and a web surfing session. A service may be instantaneous 
or persist over time. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AMA Automated Message Accounting 

AN Access Node 

CDR Call Detail Record 

CM Cable Modem 

CMS Call Management Server 

C7 Signalling System Number 7 

F ID Flow IDentifier 

HFC Hybrid Fibre Coax 

IP Internet Protocol 

MGC Media Gateway Controller 

MTA Media Terminal Adapter 

OSS Operations Support System 

QoS Quality of Service 
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PSTN 
RKS 



I'ublic Switched Telephone Network 
Record Keeping Server 



Void 



Introduction 



5.1 



IPCablecom overview 



IPCablecom is identifying and defining Specifications for delivery of enhanced communications services using 
packetized data transmission technology over the cable television hybrid fibre coax (HFC) data network running the 
J.l 12 protocol. IPCablecom specifies a network superstructure that overlays the two-way data-ready broadband cable 
access network. 

While IPCablecom is initially focused on packet voice over cable, IPCablecom will ultimately encompass additional 
voice services as well as other services such as data, video, and other real-time multimedia. 



5.2 IPCablecom Event Messages 



An Event Message is a data record containing information about network usage and activities. A single Event Message 
may contain a complete set of data regarding usage or it may only contain part of the total usage information. When 
correlated by the Record Keeping System (RKS), information contained in multiple Event Messages provides a 
complete record of the service. This complete record of the service is often referred to as a Call Detail Record (CDR). 
Event Messages or CDRs may be sent to one or more back office applications such as a billing system, fraud detection 
system, or pre-paid services processor. 

The structure of the Event Message data record is designed to be flexible and extensible in order to carry information 
about network usage for a wide variety of services. Examples of these services include IPCablecom voice, video and 
other multimedia services, such as Video-On-Demand, Pay-Per-View and J.l 12 high-speed data services. 

This IPCablecom Event Messages Specification defines a transport protocol independent Event Message attribute TLV 
format, an Event Message file format, as well as the mandatory RADIUS protocol and the optional FTP transport 
protocol. Although the scope of this Event Message Specification is limited to defining Event Messages for simple 
voice communications activities, it is expected that the present document will be expanded to support additional 
IPCablecom services as well as high-speed data services. 
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5.3 



IPCablecom reference architecture 



Figure 1 shows the reference architecture for the IPCablecom Network. Refer to the IPCablecom architecture document 
TS 101 909-2 for more detailed information on this reference architecture. 
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- Ticket Granting Server (TGS) 

- DHCP Servers 

- DNS Servers 

- TFTP or HTTP Servers 

- SYSLOG Server 

- Record Keeping Server (RKS) 

- Provisioning Server 



Figure 1 : IPCablecom network component reference model (partial) 



5.4 IPCablecom, Voice over IP over Cable 

Cable operators are deploying high-speed data communications systems and offering voice, video, and data services 
based on bidirectional transfer of Internet protocol (IP) traffic. The transfer takes place between the cable system 
headend and customer locations, over an all-coaxial or hybrid-coax/coax (HFC) cable network, defined by ITU-T 
Recommendation J.l 12. This is shown in simplified form in figure 2. 



Wide-Area 
Network 



AN 

Network Side 

Interface 



Access Node 

(AN) 




^^^ 



Cable 
Network 



Cable 
Modem (CM) 



CM Customer Premises 
Equipment Interface 




Customer 

Premises 

Equipment 



Transparent IP Traffic Through the System 



T091 1900-00 
(118823) 



Figure 2: Transparent IP Traffic through the Data-Over-Cable System 
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The transmission path over the cable system is realized at the headend by an Access Node and at each customer location 
by a CM. The intent is for operators to transfer IP traffic transparently between these interfaces. 

One critical Operations Support System (OSS) function required to operate such a system is the capturing of usage on a 
call-by-call basis for each subscriber. Such functionality is critical in allowing the operators to bill for services provided 
on a usage-sensitive basis, but also plays an important role in areas such as network usage monitoring and fraud 
management. The usage collection concept lies in requiring network elements involved in key portions of each call to 
notify a centralized Record Keeping Server (RKS) with what are termed Event Messages detailing the relevant data 
pertaining to the portion of the call handled by that given network element. This Event Message concept, and the 
architecture, which underlies it are described in greater detail in the present document. 



6 Background 

6.1 Traditional Telephony Billing Formats 

The telephony industry has traditionally recorded call detail transactions on telephone switches utilizing various 
standard and proprietary billing formats such as Automated Message Accounting (AMA). The switches generate 
multiple transactions based upon the type of call the customer placed. These transactions are correlated and packaged 
into a single Call Detail Record (CDR) at the end of the service instance for billing purposes. In this traditional 
telephony model, services and awareness of "call state" is usually maintained in one or at most two nodes of the 
network, which makes such correlation relatively straightforward. The CDR is then delivered to the billing system for 
the purpose of placing a charge on the customer's account. 

6.2 IVIotivation for Event Based Billing 

The event-based approach to capturing information to be used for billing is necessary to accommodate the distributed 
architecture of IPCablecom. "Call state awareness" no longer resides in one or two network elements, but is instead 
spread out among many. Each network element MUST be responsible for generating Event Messages for the portion of 
the communication pertaining to them. 

The primary motivating factor behind articulating the structure and details of these various Event Messages is to support 
multi-vendor interoperability between network elements and record keeping servers. The present defines the Event 
Message syntax and in addition it describes a recommended transport protocol. 

Event based billing has the added advantage that it enables IPCablecom services to be billed in real-time, making the 
information about billable communications available as the network equipment processes them. This allows the system 
as a whole to be more responsive, allowing, for example, fraudulent behaviour to be detected sooner, saving revenue for 
the provider. It also allows a more fully integrated solution, as it becomes possible for the billing system and the 
network equipment to exchange information about the availability of a service as the customer is requesting that 
service. 

With respect to the Event Message format, there are a large number of formats in use today. The most widely used 
formats carry the legacy of the traditional CDR, which is generated at the end of the call. While these formats capture 
much of the information content needed to bill for IPCablecom services, bringing along their full structure would make 
it difficult to support the real-time nature of certain enhanced IPCablecom services. The present document leverages the 
value of the information content from the existing billing formats, augmenting that with the distributed nature of the 
IPCablecom architecture. 
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6.3 Real-Time Billing 



The billing system can be regarded as a functional block of the back office Operations Support System (OSS). The 
inputs to the billing system are the billing events and the outputs are the account balance and invoice. The billing 
system relates the billing events to the account balance by rating the events according to the pricing structure and other 
business logic. 

Real-Time Billing Systems relate the billing events to the account balance as events occur. As the billing system 
receives these real-time billing events, its rating engine rates the events and immediately posts balances. Real-time 
Billing Systems may be required to support advanced IPCablecom features such as pre-paid calling card, real-time fraud 
prevention, and real-time credit enforcement. 

The IPCablecom Event Message architecture can be used to support both real-time and batch billing systems. 

6.4 Real-Time and Batch Event IVIessage Delivery 

Event Messages may be delivered to the RKS in real time as they are created. This enables support for a growing 
number of services that require purchase limits such as prepaid calling cards. 

As an alternative. Event Messages may be stored for some period of time and batched together before being sent to the 
RKS. This approach provides a more efficient use of network resources. 



6.5 Terminology and Concepts 



This clause defines terminology associated with usage data as it relates to IPCablecom Services. The concept of a "call" 
is well understood and used within the telecommunications marketplace today. A traditional telephony "call" involves 
establishing a dedicated, circuit-switched path between the calling and called parties. Packet-switched architectures, 
including IPCablecom, do not establish any such dedicated paths. To the contrary, the IPCablecom architecture assumes 
a shared medium between the head-end and the customer, as compared to the dedicated loop plant in traditional 
telephony; and during a traditional telephone call, as noted above, a circuit-switched "connection" is established 
between the parties, whereas packet switching is inherently "connectionless." All that said, the term "call" is sufficiently 
well entrenched that it will be used in the present document to refer to packet-mode voice communications between two 
parties over an IPCablecom network, even though in technical terms (as will be seen) there is little resemblance to a 
traditional telephone "call." It is envisioned that many new voice, video, data and other multimedia services will be 
developed to take advantage of the inherent extensibility of the IPCablecom architecture. These new services, which 
likely will not be derived from traditional telephony principals, will be based on the term transaction, which is more 
indicative of the data flows across the IPCablecom network. The Event Message structure is designed to be flexible and 
enable the addition of new IPCablecom services and features while maintaining backward compatibility with existing 
applications. Event Messages MAY support information required for billing of CM data services, video services, and 
the encapsulation of vendor specific proprietary data. 
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Figure 3: IPCablecom terminology 



7 IPCablecom objectives 

7.1 IPCablecom required services and capabilities 

IPCablecom provides basic voice capabilities and therefore MUST support Event Messages for the following services. 
These services are described in more detail in clause 9 of the present document. 

Interconnection with circuit-switched PSTN. 

Support for Emergency Services. 

Short Code Services. 

Freephone Services. 

Operator Services. 

Call Block Service. 

Call Waiting Service. 

- Call Forwarding/Call Redirection Services. 

Return Call Service. 

Repeat Call Service. 

Voicemail Service. 

Message Waiting Indicator Service (E-mail/Voicemail notification). 
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7.2 IPCablecom + Supported Services and Capabilities 

The following represents a list of possible additional IPCablecom services that MAY be supported. The list, though 
meant as a rough guideline, is not comprehensive, and it is expected that as the scope of services grows, so too will this 
list. A detailed definition of these services is not defined in the present document. 

3-way Communication. 

Call Transfer. 

Speed Dialling. 

Caller Name and Number. 

Caller Name and Number Privacy. 

Selective Screening Services. 

Pay-Per-Communication Services. 

Distinctive Notification (to identify callee in a multiple-party household). 

Priority Notification (to prioritize incoming communications). 

Customer Originated Trace. 

Selective Forwarding. 

Rejection (activate and deactivate). 

Teletype Translation Services. 

Multi-line Hunt Group Services. 

Virtual second line (Multiple lines). 

Alternate billing methods (collect, third number billed, credit card, pre-paid services, etc.). 

7.3 Assumptions 

The following assumptions have been made which apply to the entire document; 

IPCablecom does NOT support distributed call signalling (DCS), slated for later IPCablecom releases. 

IPCablecom assumes proprietary signalling for CMS-CMS or CMS-MGC signalling. These interfaces will be 
defined in future IPCablecom releases. 

IPCablecom does not specify the interface between an RKS and a billing system. 

All IP based Intelligent Peripherals (these include Announcement Servers, for example) will be connected to the 
originating CMS or MGC. 

IPCablecom does NOT support Line Information Database (LIDB) queries. Calls requiring LIDB determination, 
such as calling card personal identification number validation, are sent directly to the PSTN. 

IPCablecom supports local number portability (LNP). 

Non-IPCablecom network elements, such as those residing in the public switched telephone network (PSTN) to 
which an IPCablecom system may interconnect with, will NOT generate and send Event Messages to the RKS. 

PSTN Intelligent Peripheral Event Messages are generated by the originating CMS. 
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IPCablecom Event Messages currently only support messages for actual billable events. The present document 
does not specify messages related to provisioning of services by the operator of an IPCablecom network. The 
present document does support Event Messages for Subscriber service activation. The present document does not 
specify messages related to selection of an entity other than the IPCablecom network operator to handle off- 
network activities (e.g., inter-exchange communications). 

The initiating party number and the terminating party number are the only two attributes defined in IPCablecom 
that can be used to associate a subscriber with usage of network resources. 

IPCablecom supports interconnection to both Transit and Local Switches. 

IPCablecom supports an emergency Trunk Group. 

IPCablecom trusted network elements are expected to be pre-provisioned with a minimum set of data using a 
vendor-proprietary mechanism. Examples of this data may include: 

• Element Type, identifying the element as a AN, CMS, or MGC. 

• Element ID. It is assumed the Element ID will be a MAC address for IPCablecom, but in future IPCablecom 
releases may be changed to a more globally unique value, similar to the CLLI code in the PSTN. 

• Frequency (in minutes) of long-duration-call message generation (0 = never, 60 = hourly). 

• A list of which Event Messages are required and which Event Messages are optional as defined by the 
network operator. For each of these Event Messages, identify if the Event Messages are to be 1) transported 
to the RKS as a single Event Message in real-time or 2) batched and transported to the RKS as multiple 
Event Messages at a later time or 3) provide capability to configure both how many Event Messages are 
batched before being sent to the RKS. 

• number of days to keep Event Messages for short-term storage. 

• RADIUS protocol parameters: 

Retry interval and Retry count. 

For each RKS that may receive Event Messages, its IP address and UDP port. 

The IP address of each RADIUS server that it may communicate with. 
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8 Event Messages Architecture 

Figure 4 shows a representative IPCablecom Event Messages Architecture. By standardizing the transport, syntax and 
collection of appropriate Event Message attributes from a distributed set of network elements, the IPCablecom 
architecture provides a single reference point to interface to existing billing, settlement, reconcihation, and other 
systems. Note that only the shaded components are included within the scope of the IPCablecom architecture. Interfaces 
between the RKS and the shaded IPCablecom network elements are within scope of IPCablecom. Interfaces between 
the RKS and back office servers or applications are NOT within the scope of IPCablecom. It should be understood that 
the back office servers and applications shown in figure 4 are representative, and are not mandated by the IPCablecom 
architecture. 



IPCablecom Event Messages 



IPCablecom 



Network Element 



Network Element 



Network Element 




Figure 4: Representative iPCabiecom Event iVIessages Arcliitecture 

8.1 IPCablecom Event Message Collection 

Event Message collection occurs as follows: when trigger events occur (such as call signalling starts, activation of QoS 
service resources, call signalling stops, etc.), the relevant IPCablecom network element generates an Event Message. 
These messages may be sent immediately to the RKS, or a group of messages may be collected and sent at a later time. 
In either case, the actual time of the trigger event is reported allowing the back office applications to accurately 
calculate time-based resource usage. As these Event Messages are accumulated within the RKS, the network operator 
can then export them into their billing systems based on their business requirements. The data from multiple network 
elements are linked to a transaction (e.g. call) via a unique Billing Correlation identifier, which can be leveraged for 
reconciliation and non-repudiation purposes. 



8.2 



IPCablecom Network Elements 



The IPCablecom architecture supports a system capable of creating, collecting, and delivering usage data from a subset 
of IPCablecom network elements to a cable operator's back office applications. Trusted IPCablecom network elements 
that create Event Messages include the Call Management Server (CMS) Access Node (AN), Media Gateway Controller 
(MGC). 

The IPCablecom architecture contains trusted and untrusted network elements. Trusted network elements are typically 
located within a cable operator's facility and are controlled by the cable operator. Untrusted network elements are 
typically located within the consumer's home or outside of the cable operator's facility or exclusive control. In the 
IPCablecom architecture. Event messages are only accepted from trusted IPCablecom network elements. 

TS 101 909-2 contains a detailed description of the IPCablecom network elements. A brief explanation of the 
IPCablecom network elements that will most likely generate IPCablecom Event Messages is listed in this clause for 
completeness. 
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8.2.1 Call Management Server (CMS) 

The Call Management Server (CMS) provides signalling services necessary for voice communications. The primary 
purpose of the CMS is to establish standard "calls", as that term is used in the IPCablecom context. The media servers 
also provide support services for the media streams such as conference mixing bridges and announcement servers. 

The CMS MUST create a Billing Correlation ID on receipt of an NCS-signalling NTFY message from an MTA. 

The CMS MUST send the Billing Correlation ID and other data as defined in table 1 to the AN via the DQoS GateSet 
message as specified in TS 101 909-5. 

Table 1 : IPCablecom Event Reporting Common Elements 



1 Billing_Correlation_ID (see table 32). 



2 IP address and port number of the primary RKS. 



3 IP address and port number of the secondary and other RKSs (optional) 



4 Flag indicating if AN should send Event Messages to the RKS in real-time. 



The CMS MUST generate the appropriate Event Messages as defined in the present document. 

8.2.2 Media Gateway Controller (MGC) 

The Media Gateway Controller (MGC) is the overall controller function of the PSTN gateway. It receives, mediates, 
and routes call signalling information between the IPCablecom and PSTN domains and it maintains and controls the 
overall call state for all calls connecting to and from the PSTN. It controls the Media Gateway function and 
communicates with the Signalling Gateway function via the MGC-SG protocol defined for the major protocol family in 
question, i.e., ISUP, In-band or TCAP. 

The MGC MUST create a Bilhng Correlation ID on receipt of: 

an C7 lAM message, or 

a TCGP NTFY with digits (operator services). 

The MGC MUST generate the appropriate Event Messages as defined in the present document. 

8.2.3 Access Node (AN) 

The Access Node terminates the connection from the CM on the customer premises into the IPCablecom network. The 
AN generates QoS Event Messages. 

The AN MUST generate the appropriate Event Messages as defined in the present document. 

8.2.4 Record Keeping Server (RKS) 

The Record Keeping Server (RKS) is a trusted network element function. In many cases, for simplicity reasons, the 
RKS is depicted in the present document as a separate standalone element, but the present document does not preclude a 
CMS, Billing System, or other application from performing the RKS functionality. The RKS is the mediation layer 
between the call signalling and transport layer and the back-office applications. The RKS is expected to pre-process the 
data from the Call Signalling and Transport layer and present it to the back-office applications in the format and within 
the time constraints deemed necessary by the operator. 

The RKS also, at a minimum, is a short-term repository for IPCablecom Event Messages. It receives Event Messages 
from various trusted IPCablecom network elements. The RKS assembles the Event Messages into coherent sets, which 
are then made available to a usage-processing platform and potentially to several other back office systems. It acts as 
the demarcation point between the IPCablecom network and the back office applications. 
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The RKS is expected to perform the following functions: 

The RKS MUST receive Event Messages. 

The RKS MUST be capable of correlating all Event Messages related to an individual call and have an 
extensible output to meet the needs of the downstream applications. 

The RKS MUST assemble Events and Determine Completeness - this MUST include the capability to 
distinguish Event Messages, and recognize when a complete set, representing a coherent set of billing data is 
available for transport to the back office system. 

The RKS MUST provide interface network functions that require real time or near real time based on priority 
and where messages are being sent, as defined in clause 10. For example, a call may be sent real-time and a 
report may be sent at night. The correlation process MUST be user definable to support the various call events 
defined herein and defined in the future. 

The RKS MUST have the ability to store the Event Messages for at least one week or until sent to the other back 
office systems and successful receipt is acknowledged from those systems. 

The RKS MUST have the ability to dump the Event Messages to some other type of offline storage device on a 
regular basis (CD, TAPE, or other media) for retrieval and regulatory purposes. 

The following list deals with other possible capabilities of an RKS. They are therefore beyond the scope of the 
requirements of the current document, and are included here for informational use only. Decisions on these optional 
requirements will be based upon the operator response to many regulatory and business variables. 

An RKS-RKS security interface MAY be required. IPCablecom does not define this interface. The security 
interface between the RKS and other IPCablecom trusted network elements is defined in TS 101 909-1 1 
IPCablecom Security Specification. 

The RKS MAY support Backup and Recovery - this includes a nominal ability to restore the state and contents 
of billing data in the event of application or platform failures. 

The RKS MAY support distribution of billing data to all appropriate systems - this includes the implementation 
of a protocol that ensures data integrity and reliability on the usage collator interface. 

The RKS MAY support monitoring and reporting - this includes the ability to produce and send alarms to a 
network management system, and create various audit and measurement reports. 

The RKS MAY allow remote testing and maintenance capability. 

The RKS MAY support a Service Creation Environment. 

The RKS MAY support user defined fault handling in the case of incomplete Event Messages or other such 
anomahes. 

The RKS MAY support multiple downstream applications, and various transport methodologies. 

The RKS MAY support full auditability of data and processes. 

The RKS MAY support a user definable long-term storage mechanism. 

The RKS MAY support disaster planning and recovery processing. 
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8.3 General IPCablecom Network Element Requirements 

This clause lists requirements placed on the IPCablecom network elements: 

The CMS and AN MUST create a security relationship with each RKS that these network elements will send 
Event Messages as defined in TS 101 909-1 1. The MGC MUST create a security relationship with each RKS 
that the MGC will send Event Messages. 

The CMS MUST support multiple primary RKSs, which might be required in cases in which total Event 
Message traffic exceeds the throughput capability of a single RKS. 

- For each call, the CMS or the MGC MUST create a unique Billing_Correlation_ID, identify the primary and all 
other RKSs and determine if the Event Messages are to be delivered in real time or they may be batched and sent 
at a later time. 

The trusted IPCablecom network elements that generate Event Messages MUST timestamp Event Messages in 1 
millisecond granularity +100 ms based on information reported by network time sources such as edge devices 
(Clients and Gateways). 

All IPCablecom network elements that generate Event Messages MUST synchronize their clocks at least once 
per hour to a network clock source. This synchronization MUST assure the reporting device's own clock remains 
within ±100 ms real time of the last synchronization value. 

IPCablecom network elements that generate Event Messages MUST support system wide Network Time 
Protocol (NTP) time synchronization. 

The IPCablecom network elements MUST support transport to multiple RKSs for processing system 
segmentation, downstream overload conditions, and disaster recovery. 

IPCablecom network elements MUST support the transport of a single Event Message as well as a batch of 
Event Messages. 

NOTE: Batch mode = multiple Event Message per single Radius message. 

Each trusted IPCablecom network element that generates an Event Message MUST identify itself with a static, 
unique element ID. 
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8.4 Event Message Interfaces 



This clause describes the interfaces between the IPCablecom network elements that are involved in the Event Messages 
process. It should be noted that additional requirements are imposed on these by other IPCablecom Specifications and 
that the requirements listed in the present document are specific to Event Messages. It should also be noted that 
additional requirements are specified for these interfaces and these IPCablecom network elements in other clauses of 
the present document. 




pk;t-em2 (see note) 



pkt-em5 




pkt-emS 



pkt-eml(see note) 




pkt-em4 




T091 1930-00 
(118823) 



NOTE: It indicates tliat the Billing Correlation ID and other data defined in table 1 is carried on an existing 
signalling interface. 

Figure 5: Event Message Billing Interfaces 

8.4.1 CMStoAN(pkt-em1*) 

The CMS to AN interface is defined by the IPCablecom DQoS protocol TS 101 909-5. 

The CMS sends the Billing Correlation ID and other data as defined in table 1 to the AN via the DQoS GateSet message 
as specified in TS 101 909-5. 

8.4.2 CMS to MGC (pkt-em2*) 

The CMS to MGC interface is vendor proprietary in IPCablecom. This interface will be defined in a future IPCablecom 
Specification. 

If the CMS routes a call to the MGC, then the CMS MUST send the Billing Correlation ID and other data as defined in 
table 1 to the MGC via a vendor-proprietary interface. 

If the MGC routes a call to the CMS, then the MGC MUST send the Billing Correlation ID and other data as defined in 
table 1 to the CMS via a vendor-proprietary interface. 

8.4.3 CMS to RKS (pkt-em3) 

The CMS to RKS interface is defined by TS 101 909-1 1 and also by the Event Message transport and syntax rules 
defined in the present document. 

8.4.4 AN to RKS (pkt-em4) 

The AN to RKS interface is defined by TS 101 909-1 1 and by the Event Message transport and syntax rules defined in 
the present document. 
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8.4.5 MGC to RKS (pkt-em5) 

The MGC to RKS interface is defined by the TS 101 909-1 1 and by the Event Message transport and syntax rules 
defined in the present document. 

8.4.6 Security Requirements 

When the network IPSec Security Associations are established, security keys MUST be created and exchanged between 
each RKS (primary, secondary, etc.) and every CMS, and AN that will send Event Messages to any of those RKSs. A 
security association MUST exist between the MGC and RKS and is left to vendor implementation in IPCablecom. The 
Event Messages are sent from the CMS and AN to the RKS using one of the supported transport protocol mechanisms, 
each of which must be possible to secure by IPSec. Refer to TS 101 909-1 1 for a detailed description of the security 
requirements for the IPCablecom Event Message interfaces. 

8.4.7 Storage Requirements 

IPCablecom network elements that generate Event Messages MUST support storage of Event Messages in a secure 
manner, until an acknowledgment from an RKS for those Event Messages is received. The RKS MUST have the ability 
to store the Event Messages for at least one week or until sent to the other operating systems and successful receipt is 
acknowledged from those systems. The RKS must also have the ability to dump the Event Messages to some type of 
off-line storage device on a regular basis (CD, TAPE, or other media) for retrieval and regulatory purposes. 



9 IPCablecom Services and Their Associated Event 

IVIessages 

This clause defines the supported IPCablecom Services and their associated Event Messages. Although many of the 
IPCablecom + services can be billed using the Event Messages and attributes defined in the present document, the 
services described in this clause are currently limited to IPCablecom services. 

In order to identify appropriate Event Messages required for each service, representative call flows were developed for 
IPCablecom basic call configurations. 

9.1 IPCablecom Call Configurations 

This clause describes the three basic IPCablecom call configurations: On-Net to On-Net, On-Net to Off-Net, and Off- 
Net to On-Net. A required minimum set of Event Messages MUST be generated for each of these three basic call 
configurations. If specific services are initiated in along with the basic call, then refer to clause 9.2 for a list of 
additional Event Messages for these specific services. 
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9.1 .1 On-Net to On-Net Call Configuration 

The most basic IPCablecom call configuration is an On-Net to On-Net call within a single operator's network, using two 
difl^erent MTAs that are both connected to the same CMS. For IPCablecom, it is assumed that both the originating and 
terminating MTAs are using the same CMS and possibly two diflierent ANs. 

Table 2: On-Net to On-Net Call Configuration 



Event Message 


Required or 
Optional 


Comments 


Signalling_Start 


R 


CMS is starting signalling to support a call 
start. 


QoS Start 


R 


For Calling Party. 


QoS Start 


R 


For Called Party. 


Database Query 


Q 


If LNP is required. 


lntelligent_Peripheral_Usage_Start 


Q 


e.g. if an announcement is needed 
(see note). 


lntelligent_Peripheral_Usage_Stop 


Q 


e.g. if an announcement is needed 
(see note). 


Call Answer 


R 


Indicates start of media stream. 


Signalling Stop 


R 


Generated for whichever party hangs up first. 


Call Disconnect 


R 


Indicates termination of media steam. 


QoS Stop 


R 


For Calling Party. 


QoS Stop 


R 


For Called Party. 


NQTE: This Event Message will be defined in a future release of this IPCablecom Specification. 



9.1 .2 On-Net to Off-Net Call Configuration (Outgoing PSTN Interconnect) 

The only OflLNet interconnection supported by IPCablecom is to the PSTN. Therefore the CMS sends all OflLNet calls 
to the PSTN. The Interconnect_Start Event Message identifies the type of Off_Net trunk. The Off_Net call may require 
an LNP query. The CMS MUST generate a database query Event Message each time a LNP database is accessed 
(regardless of whether this query is requested from a PSTN database or IP database). 

Table 3: On-Net to Off-Net Call Configuration 



Event Message 


Required or 
Optional 


Comments 


Signalling_Start 


R 


CMS is starting signalling to support a call 
start. 


QoS Start 


R 


For Calling Party. 


Database Query 


Q 


If LNP is Required. 


lntelligent_Peripheral_Usage_Start 


Q 


e.g. if an announcement is needed 
(see note). 


lntelligent_Peripheral_Usage_Stop 


Q 


e.g. if an announcement is needed 
(see note). 


Interconnect Start 


R 


For call setup. 


Call Answer 


R 


Indicates start of media stream. 


Signalling Stop 


R 


Generated for whichever party hangs up first. 


Interconnect Stop 


R 


For call tear-down. 


Call Disconnect 


R 


Indicates termination of media steam. 


QoS Stop 


R 


For Calling Party. 


NOTE: This Event Message will be defined in a future release of this IPCablecom Specification. 
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9.1 .3 Off-Net to On-Net Service (Incoming PSTN Interconnection) 

The CMS receives calls that are incoming from other entities and establishes communications with the MTA on the 
operator's network. For IPCablecom, it is assumed that all incoming calls are from the PSTN. 

Table 4: Off-Net to On-Net Call Configuration 



Event Message 


Required or 
Optional 


Comments 


Interconnect Start 


R 


For call setup. 


QoS Start 


R 


For Called Party. 


lntelligent_Peripheral_Usage_Start 





e.g. if an announcement is needed 
(see note). 


lntelligent_Peripheral_Usage_Stop 





e.g. if an announcement is needed 
(see note). 


Signalling_Start 


R 


CMS is starting signalling to service a request 
to start a call. 


Call Answer 


R 


Indicates start of media stream. 


Signalling Stop 


R 


Generated for whichever party hangs up first. 


lnterconnect_Stop 


R 


For call tear-down. 


Call Disconnect 


R 


Indicates termination of media steam. 


QoS Stop 


R 


For Called Party. 


NOTE: This Event Message will be defined in a future release of this IPCablecom Specification. 



9.2 Specific Services 



A basic set of Event Messages MUST be generated based on the type of call configuration: On_Net to On_Net, On_Net 
to Off_Net, Off_Net to On_Net. The basic set of Event Messages is described in clause 9.1. 

This clause describes additional Event Messages that MUST be generated along with the basic set in order to describe 
specific IPCablecom services. This clause also describes optional Event Messages that MAY be generated along with 
the basic set and any additional required Event Messages. These additional required and optional Event Messages are 
identified in the tables in this clause. It is expected that these additional Event Messages will be able to be generated 
regardless of the particular implementation of the service. 

9.2.1 Emergency Service 

An emergency call follows the standard On-Net to Off-Net Event Message flow described above in clause 9.1.2, 
emergency calls require special treatment. In IPCablecom, it is assumed that the operator sends emergency calls to the 
PSTN on a special trunk. The Trunk Group ID is captured in the Interconnect_Start and Interconnect_Stop Event 
Messages, and it is assumed that the RKS or some element downstream of the RKS has the capability of inferring this 
trunk group type from that unique Trunk Group ID. 

No additional Event Messages are required beyond the basic ones listed for an On_Net to Off_Net call in clause 9.1.2. 

9.2.2 Other Short Code Services 

These calls are identical to the emergency call both from a call flow and Event Message perspective. The determination 
of whether to bill or not can be performed at the Billing System based on the "Called Party Number" attribute. For 
example, charges for calls to directory assistance may be different than charges for emergency calls, which are free, but 
the Event Messages, which capture the usage for both types of services, are the same. They would differ only in the 
content of specific attribute values such as the Called_Party_Number within the Call_Answer Event Message. The 
billing system is expected to make a determination as to how much to bill the customer based on these attributes 
together with other factors such as whether the call is completed or not. 
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9.2.3 Freephone Services 

Freephone Services follow the standard On-Net to Off-Net Event Message flow described above in clause 9.1.2. In 
IPCablecom, toll-free calls can be handled two ways: 

Send all Toll-free calls to the PSTN on a special trunk. The call is treated exactly like the emergency services 
case discussed above in clause 9.2.1 in terms of Event Messages, meaning that no additional Event Messages are 
required. 

Initiate a query to the toll-free SCP (in IP or PSTN) and, depending on the specified Carrier Identification Code, 
route the call to the appropriate network. A Database_Query Event Message MUST be generated to record the 
query to the toll-free database. 

Table 5: Toil-Free Services 



Additional Event IVIessages 


Required or Optional 


Comments 


Database_Query 


R 


Not used for scenario 1 but required for 
scenario 2. 



9.2.4 Operator Services 



Operator Services follow the standard On-Net to Off-Net Event Message configuration described above in clause 9.1.2. 
There will be no new additional Event Messages beyond those already described for the On-Net to Off-Net calls in that 
clause. The CMS will send that call to the designated Operator Service F*rovider using the PSTN. There may be multiple 
Operator Service Providers with which the operator has contracts. The caller will just dial the normal code for operator 
services. 

The CMS will generate an event identifying that call as a short code number dialled without any subsequent digits by 
using an appropriate value in the Called number field. The CMS will replace the short code in the Called Number field 
with the number of the Operator Service Provider (OSP). These parameters will be sent to PSTN so that call can be sent 
via PSTN to the OSP. It is assumed that dedicated private lines to the OSP from each IP-switch are impractical and 
expensive for operators, and not considered as an option. 

For the purposes of IPCablecom, it is assumed that operator services only encompasses short code services. Short code 
plus service, in which the customer keys the dialled number in together with the initial short code, is not supported in 
IPCablecom. 

9.2.5 Call Block Service 

Event Messages are generated for Call Block Service only if the CMS blocks a call. Call Blocking is supported by all of 
the three basic call configurations: On_Net to On_Net, On_Net to Off_Net, and Off_Net to On_Net. 

The CMS can block calls depending on the policies laid out by the operator. For example, the operator may allow the 
end-user to block all 900 calls at the user's request. As another example, the operator may recognize some calls as 
fraudulent and block those fraudulent calls. In this case an Event Message needs to be generated with some reason 
attributes as to why the call was blocked. In addition, depending on the type of blockage, the operator may desire to 
play an appropriate announcement (e.g. "Sorry your time is up . ..."). The CMS may initiate another call to the 
Announcement Server via the PSTN and play it to the caller. A series of Event Messages will be generated for this call, 
using the same Billing_Correlation_ID as the standard Event Messages associated with the off-hook, dialing, etc., 
which is not expected to be used for billing this call to the end-user. 

Table 6: Call Block Service 



Additional Event IVIessages 


Required or Optional 


Comments 


Service Instance 


R 


none 


Intelligent Peripheral Usage Start 





see note 


Intelligent Peripheral Usage Stop 





see note 


NOTE: This Event Message will be defined in a future release of this IPCablecom Specification. 
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9.2.6 Call Waiting Service 



At any given time the caller may be talking and will hear the call waiting tone when another call is incoming. It is 
understood that at some point prior to this call, the called party subscribed to call waiting service. The called party can 
switch back and forth between the two calls by using the flash hook. Call Waiting can be supported by any of the three 
basic call configurations: On_Net to On_Net, On_Net to Off_Net, and Off_Net to On_Net. 

The call flow is as follows: 

There is an existing call to a number connected via the MT A/ AN/CMS. Another call attempt is made to that number, 
the CMS: 

Verifies that an existing call is already in progress; 

Checks its internal database to verify whether the called party has subscribed to Call Waiting, if yes: 

• Establishes a voice connection to the Announcement Server (which will play the call waiting tone), 

• Creates a Event Message indicating that Call Waiting is being initiated, 

• Mixes the two voice calls (the currently established voice call and the Call Waiting tone voice call) so that 
the called party can hear the call waiting tone. 

It is assumed that Call Waiting only supports two calls (one active and the other on hold) in IPCablecom. The call on 
hold will not be connected to any announcement server. 

Both of the calls between which the subscriber is switching will generate a complete set of Event Messages on their 
own as detailed in clauses 5.1.2 and 9.1.3, but there may also be three additional Event Messages associated with this 
instance of Call Waiting, as detailed below. If the Announcement Server is located on the PSTN, then the previously 
discussed Call_Answer and Call_Disconnect Event Messages will be generated for this call. 

Table 7: Call Waiting Service 



Event Message 


Required or Optional 


Comments 


lnterconnect_Start 





Required only if Announcement Server for 
Call Waiting tone is Off Net on PSTN. 


lnterconnect_Stop 





Required only if Announcement Server for 
Call Waiting tone is Off Net. 


lntelligent_Peripheral_Usage_Start 





Required only if Announcement Server 
On Net (see note). 


lntelligent_Peripheral_Usage_Stop 





Required only if Announcement Server 
On Net (see note). 


Service Instance 


R 


none. 


NOTE: This Event Message will be defined in a future release of this IPCablecom Specification. 
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9.2.7 Call Forwarding Service 

Call Forwarding Service applies only to calls terminating On_Net as described in clauses 9.1.1 and 9.1.3. 

The CMS gets notification that a call needs to be completed to a specific dialled number/end device. The CMS checks 
its internal database and determines that the called number has subscribed to Call Forwarding, Call Forwarding is 
currently active, and the forwarding number is XYZ. The CMS will initiate ANOTHER call with the new Calling Party 
Number as the old Dialled number and the Forwarded Number (XYZ) as the new Dialled Number. Event Messages will 
be generated for the fact that a Call Forwarding instance was initiated. The Billing_Correlation_ID for this leg will be 
different than the first call. The rationale for using the Related Billing Correlation ID as the common identifier for call 
forwarding is that it may be desirable to flag calls made automatically by invocation of call forwarding on the 
subscribers monthly statement in order to make it clear the reason those calls were placed. For all purposes the original 
call and the forwarded call will be two different billable calls. 

Table 8: Call Forwarding Service 



Event Message 


Required or Optional 


Comments 


Service Instance 


R 


none 



9.2.8 Return Call Service 

This service applies only to calls originating On_Net, described in clauses 9.1.1 and 9.1.2. The CMS MUST keep a 
register with the Calling Party Number of the last call. 

Return Call Service will return the last call that was made to an MTA. Upon instantiation of Return Call feature, the 
CMS will initiate another call with the Calling Party Number of the last call, retrieved from the register just described, 
as the Dialled number. Event Messages will be generated for the fact that the Return Call feature was initiated, using the 
Billing_Correlation_ID of this call. If the Calling Party Number of the last call had Caller ID privacy restrictions, then 
CMS may conference in a recording from an announcement server saying that this call can not be completed. 

Table 9: Return Call Service 



Event IWessage 


Required or Optional 


Comments 


Service Instance 


R 


none. 


lnterconnect_Start 





Required only if Announcement Server for 
delivering the Message indicating reason 
Return Call cannot be activated is Off Net 
on PSTN. 


lnterconnect_Stop 





Required only if Announcement Server for 
delivering the Message indicating reason 
Return Gall cannot be activated is Off Net 
on PSTN. 


lntelligent_Periplieral_Usage_Start 





Required only if Announcement Server for 
delivering the Message indicating reason 
Return Gall cannot be activated is OnNet 
(see note). 


lntelligent_Periplieral_Usage_Stop 





Required only if Announcement Server for 
delivering the Message indicating reason 
Return Gall cannot be activated is On_Net 
(see note). 


NOTE: Tliis Event IVlessage will be defined in a future release of this IPCablecom Specification. 
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9.2.9 Repeat Call Service 

Repeat Call Service applies only to calls terminating On_Net as described in clauses 9.1.1 and 9.1.3. 

Repeat Call can be initiated when the caller dials a number and gets a busy signal. With this feature the caller dials a 
special pre-determined string of digits (*66 in USA) which then instructs the network to keep polling the called and 
calling party and when both free, establish the communication. In IPCablecom, the originating CMS will keep trying to 
establish communications to the called number for a pre-determined amount of time. 

Table 10: Repeat Call Service 



Event Message 


Required or Optional 


Comments 


Service Instance 


R 


none. 


lnterconnect_Start 





Required if Announcement Server for 
delivering the Message indicating reason 
Repeat Call cannot be activated is Off Net 
on PSTN. 


lnterconnect_Stop 





Required only if the appropriate 
Interconnect Start was activated. 


lntelligent_Peripheral_Usage_Start 





Required only if Announcement Server for 
delivering the Message indicating reason 
Repeat Call cannot be activated is On_Net 
(see note 1). 


lntelligent_Peripheral_Usage_Stop 





Required only if Announcement Server for 
delivering the Message indicating reason 
Repeat Call cannot be activated is 
On Net (see note 1). 


NOTE 1 : This Event IVIessage will be defined in a future release of this IPCablecom Specification. 
NOTE 2: There may be multiple lnterconnect_Start and Stops capturing the multiple different times the 
originating CMS tries to make an Off-Net call to try to complete a Repeat Call request. 



9.2.10 Voicemail Service 

Voicemail Service only applies to calls terminating On_Net, described in clauses 9.1.1 and 9.1.3. 

It is assumed that the voicemail server will be located Off_Net for IPCablecom. It is therefore assumed if voicemail 
billing is usage sensitive, that connections to the Off_Net voicemail system will be counted in the same way whether 
they are voicemail messages being left for the subscriber (deposit) or calls to retrieve the messages on the voicemail 
server. 

Voicemail deposit and retrieval scenarios will be treated as separate transactions that have associated Event Messages. 
Event Messages for voicemail deposit will look like a standard On_Net to Off_Net call. When the call is transferred to 
the Voicemail Server, the Routing Number MUST be captured and populated with the Voicemail Server Address. 

The connection time to the Voicemail Server MAY also be derived through the standard On_Net to Off_Net Event 
Messages. Since the Voicemail Server is located Off_Net, Event Messages for voicemail retrieval MAY only be 
generated if the retrieval is initiated from a device within the operator's network (e.g. On_Net to Off_Net call). 

9.2.11 Message Waiting Indicator Service 

It is assumed that an Off_Net voicemail system is used as described in clause 9.2.10. Because it seems unreasonable for 
the CMS to have to place a separate call to the Off_Net system each time a voicemail subscriber goes off-hook, it is 
assumed that a mechanism exists which allows the Off_Net voicemail system pass the information to the CMS 
indicating which subscribers have voicemail waiting. A further assumption is that the MTA is capable of delivering the 
audible stutter-tone message- waiting indicator to the subscriber's MTA port going off-hook, on the command of the 
CMS. 

Under the scenario described in the assumptions clause, and given the fact that billing will not be based on any per use 
delivery of the stutter tone, there will be no Event Messages required for this service. Billing will be based on a 
combination of information obtained from the Voicemail send/retrieve Event Messages discussed in clause 9.2.10 and 
provisioning information indicating when a subscriber has signed up for voicemail services. 
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10 IPCablecom Event Message Structure 

This clause describes the various Event Messages, together with their associated list of attributes. Refer to clause 1 1 for 
a detailed description of the attributes described in this clause. Refer to clause 9 a detailed description of the services 
and their associated Event Messages. 

The following tables show the association between IPCablecom services, supported by the aforementioned call 
configurations, and proposed Event Messages that may be generated for each service. Voice communications services 
that IPCablecom will provide are based on three main call configurations; 

- On-Net to On-Net; 

- On-Net to Off-Net; 

- Off-Net to On-Net. 

Table 1 1 provides a list of IPCablecom Event Messages defined in the present document. More than one set of Event 
Messages MAY be generated during a particular service instance. 

Table 11 : IPCablecom Event Message Summary 



Event 
Message ID 


IPCablecom Event Message 


Description 





Reserved 




1 


Signalling_Start 


Start of signalling for originating or terminating 
part of the call. 


2 


Signalling_Stop 


Stop of signalling for originating or terminating 
part of the call. 


3 


Database_Query 


An inquiry into an external database; for 
example a toll-free number database. 


4 


Intelligent Peripheral Usage Start 


Deferred. 


5 


Intelligent Peripheral Usage Stop 


Deferred. 


6 


Service Instance 


Indicates an occurrence of a service. 


7 


QoS_Start 


Start of QoS for originating or terminating part 
of the call. 


8 


QoS_Stop 


Stop of QoS for originating or terminating part 
of the call. 


9 


Service Activation 


Indicates a subscriber has activated a service. 


10 


Service_Deactivation 


Indicates a subscriber has deactivated a 
service. 


11 


Undefined 




12 


Undefined 




13 


lnterconnect_(Signalling)_Start 


Start of network interconnect signalling 
(between IPCablecom and PSTN) for 
originating or terminating part of the call. 


14 


lnterconnect_(Signalling)_Stop 


Stop of network interconnect signalling 
(between IPCablecom and PSTN) for 
originating or terminating part of the call. 


15 


Call_Answer 


Indicates that all network resources for have 
been allocated for originating or terminating 
part of the call. 


16 


Call_Disconnect 


Indicates that all network resources for have 
been released for originating or terminating 
part of the call. 


17 


Time Change 


Indicates time change on a network element. 


19 


QoS_Ghange 


Indicates a change in QoS. 
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Table 12: Services supported by On-Net to On-Net call configuration 



Service 


Event Message ID 




1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 


Basic 


X 


X 


X 


X 


X 




X 


X 






(= 
-z. 
o 
m 
■n 

-z. 
m 
o 


<= 
z: 
o 
m 
■n 

-z. 
m 

D 






X 


X 






Call Block 


X 


X 




X 


X 


X 


X 


X 


X 


X 






X 


X 






Call Waiting 


X 


X 




X 


X 


X 


X 


X 


X 


X 






X 


X 






Call Forwarding 


X 


X 




X 


X 


X 


X 


X 


X 


X 






X 


X 






Return Call 


X 


X 




X 


X 


X 


X 


X 










X 


X 






Repeat Call 


X 


X 




X 


X 


X 


X 


X 










X 


X 






Voicemail 


X 


X 




X 


X 




X 


X 










X 


X 







Table 13: Services supported by On-Net to Off-Net call configuration 



Service 


Event Message ID 




1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 


Basic 


X 


X 


X 


X 


X 




X 


X 






C 

-Z. 
o 
m 
-n 

z 
m 
o 


c 
z 
o 
m 
-n 

z 
m 
o 


X 


X 


X 


X 






Call Block 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 






Call Waiting 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 






Return Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 


X 


X 






Repeat Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 


X 


X 






911 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 






Nil 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 






Toil-Free 


X 


X 


X 


X 


X 




X 


X 






X 


X 


X 


X 






Operator 


X 


X 




X 


X 




X 


X 






X 


X 


X 


X 







Table 14: Services supported by Off-Net to On-Net call configuration 



Service 


Event Message ID 




1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 


Basic 


X 


X 


X 


X 


X 




X 


X 






c 
z 
o 
m 
■n 

z 
m 
o 


c 
z 
o 
m 
■n 

z 
m 
o 


X 


X 


X 


X 






Call Block 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 






Call Waiting 


X 


X 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 






Repeat Call 


X 


X 




X 


X 


X 


X 


X 






X 


X 


X 


X 






Call Forwarding 


X 


X 




X 


X 


X 


X 


X 


X 


X 






X 


X 






Voicemail 


X 


X 




X 


X 




X 


X 






X 


X 


X 


X 







10.1 Event Message Structure 



An Event Message contains a header followed by attributes. The header is required on every Event Message. The 
attributes will vary based on the type of service the Event Message is describing. Refer to table 31 for a description of 
the Event Message Header. Example information contained in the header includes: version of Event Message structure, 
timestamp indicating when the trigger event occurred, Billing Correlation ID used to associate multiple Event Messages 
with a single service. Example information contained in attributes includes: Called Party Number, Calling Party 
Number, Trunk Group ID. 



Header 


Attribute #1 


Attribute #2 


Attribute #3 




Attribute #n 
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10.2 Servicejnstance 

This event captures the fact that a service event has happened. The Event_Time attribute in the Event Message Header 
(see table 31) MUST contain the time at which the service occurred. 

This Event Message indicates the time at which the CMS provides an instance of a call control/feature service. For 
example, the time at which a call is put on hold, the time at which a call is forwarded, the time at which a last call return 
service is provided, the time at which a call-waiting service is provided, etc. 

The CMS MUST timestamp these messages immediately upon operation of the service instance being reported. 

Table 15: Servicejnstance Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Service_Name 


R 


Class Service name: 

1 CalLBIock 

2 Call Forward 

3 CalLWaiting 

4 Repeat_Call 

5 Return Call 


Call Termination Cause 





1 = Required in the case of Call Block. 


Related_Call_Billing_Correlation_ID 





2, 3 = Required in the case of Call Forward or 
Call Waiting. 


Charge_Number 





2, 3, 4, 5 = Required in the case of Call 
Forward, Call Waiting, Repeat Call, Return 
Call. 


First Call Calling Party Number 





3 = Required in the case of Call Waiting. 


Second_Call_Calling_Party_ 
Number 





3 = Required in the case of Call Waiting. 


Cal led_Party_Num ber 





3 = Required in the case of Call Waiting. 


RoutingNumber 





4, 5 = Required in the case of Repeat Call or 
Return Call. 


Calling_Party_Number 





4, 5 = Required in the case of Repeat Call or 
Return Call. 



10.3 Service_Activation 

This event captures a subscriber activating a service. The Event_Time attribute in the Event Message Header (see 
table 31) MUST contain the time when the service was activated. 

This Event Message indicates the time at which the CMS records an attempt to activate a service. For example, the time 
at which call-forwarding is activated by the MTA user, the time at which the call-waiting service is activated by the 
MTA user, etc. These service activations are typically requested via a *XX dial-string. 

The CMS MUST timestamp this message immediately upon successful activation of the requested service. 

NOTE: Failed activation attempts are not reported at this time. 

The CMS MUST create a new Billing Correlation ID for this Event Message even if a service is activated during an 
existing call. 
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Table 16: Service_Activation Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Service_Name 


R 


Class Service name: 

1 CalLBIock 

2 Call Forward 

3 Call Waiting. 


Forwarded Number 





Required. 



10.4 Signalling_Start 



This Event Message indicates the time at which signalling starts. The originating CMS or MGC MUST issue this Event 
Message for any given call. 

The CMS or MGC MUST timestamp this message prior to digit translation. Note that the attributes contained in this 
Event Message contain information that is obtained after digit translation. 

The CMS MUST timestamp this message immediately upon receipt of: 

a NCS-signalling NTFY message with a routable set of digits that indicate a call attempt. 

The MGC MUST timestamp this message immediately upon receipt of: 
a C7 lAM message, or 
- a TGCP NTFY with digits (operator services). 

Table 17: Signalling_Start Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Direction indicator 


R 


none. 


MTAEndpointName 


R 


This attribute if required when the CMS 
generates this message. This attribute is NOT 
required when the MGC generates this 
message. 


Calling Party Number 


R 


none. 


Cal led_Party_Num ber 


R 


none. 


Carrier_ldentification_Code 





This attribute MUST be included when the 
MGC generates this message. 


TrunkGroupJD 





This attribute MUST be included when the 
MGC generates this message. 



10.5 Signalling_Stop 



This Event Message indicates the time at which signalling terminates. 

The CMS MUST timestamp this message immediately upon receipt of the last signalling event in the following list: 
acknowledgement of the CMS-issued NCS-signalling DLCX message; 
transmission of the acknowledgement of an MTA-issued NCS-signalling DLCX message; or 
the last signalling message to/from a peer CMS or MGC associated with this call. 
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The MGC MUST timestamp this message immediately upon receipt of the last signalling event in the following list: 
transmission/receipt of an RLC to/from the Signalling Gateway that communicates with the C7 network; 
- receipt of the acknowledgement of the MGC -issued TGCP DLCX; 

transmission of the acknowledgement of an MG-issued TGCP DLCX; or 
transmission/receipt of the last signalling message to/from a CMS associated with this call. 

Table 18: Signalling_Stop Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Direction indicator 


R 


none. 


MTA_Endpoint_Name 


R 


Tliis attribute IVIUST be included if the CMS 
generates this message. This attribute is NOT 
required if the MGC generates this message. 



10.6 Service_Deactivation 

This Event Message indicates the time at which the CMS records an attempt to deactivate a service. For example, the 
time at which call-forwarding is deactivated by the MTA user, the time at which the call-waiting service is deactivated 
by the MTA user, etc. These service deactivations are typically requested via a *XX dial-string. 

The CMS MUST timestamp this message immediately upon successful deactivation of the requested service. Failed 
Deactivation attempts are not reported at this time 

The CMS MUST create a new Billing Correlation ID for this Event Message even if a service is deactivated during an 
existing call. 

Table 19: Service_Deactivation Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none 


Service Name 


R 


none 



10.7 Database_Query 



This Event Message indicates the time at which a one-time request/response transaction or database dip is completed by 
an intelligent peripheral (Freephone database, LNP database, etc.). 

The CMS originating the call MUST timestamp this message immediately upon a receipt of the response from the 
Intelligent Peripheral. 

Table 20: Database_Query Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(table 31) 


R 


none. 


Database ID 


R 


none. 


Query Type 


R 


Freephone Number Lookup, LNP lookup, etc. 


Called Party Number 


R 


none. 


Returned Number 


R 


see note. 


NOTE: There may be multiple numbers returned. If multiple numbers are returned this Attribute MUST 
be included for each number returned. 
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1 0.8 lntelligent_Peripheral_Usage_Start 

Deferred. 

1 0.9 lntelligent_Peripheral_Usage_Stop 

Deferred. 

10.10 lnterconnect_Start 

This Event Message indicates the time at which the start of network interconnect occurs. Only the MGC is permitted to 
issue this Event Message. 

The MGC MUST timestamp this message immediately upon commitment of bandwidth between the IPCablecom 
network and the PSTN. 

Table 21 : lnterconnect_Start Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Carrier Identification Code 


R 


CIC Code of connecting operator. 


TrunkGroupJD 


R 


TGID of the trunk over which the 
interconnection is occurring. 


Routing Number 


R 


none. 



10.11 lnterconnect_Stop 



This Event Message indicates the termination of bandwidth between the IPCablecom network and the PSTN. Only the 
MGC is permitted to issue this Event Message. 

The MGC MUST timestamp this message immediately upon release of bandwidth between the IPCablecom network 
and the PSTN. 

Table 22: lnterconnect_Stop Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Carrier Identification Code 


R 


CIC Code of connecting operator. 


TrunkGroupJD 


R 


TGID of the trunk over which the 
interconnection is occurring. 
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10.12 Call_Answer 

This Event Message indicates that the media connection is open because answer has occurred. The terminating CMS or 
MGC MUST generate this Event Message. The originating CMS or MGC MAY generate this Event Message. 

The CMS MUST timestamp this message immediately upon receipt of: 

a NCS-signalling NTFY message indicating off-hook at the destination MTA. 
The MGC MUST timestamp this message immediately upon receipt of: 

a C7 ANS message from the PSTN; or 

an answer indication from the MG indicating answer has occurred on an operator services trunk. 

Table 23: Call_Answer Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Cal led_Party_Num ber 


R 


none. 


Routing Number 


R 


none. 


Charge Number 


R 


none. 


Location Routing Number 


R 


For local number portability use. 



10.13 Call_Disconnect 

This Event Message indicates the time at which the media connection is closed because the calling party has terminated 
the call by going on-hook, or that the destination party has gone on-hook and the called-party's call-continuation timer 
has expired (see note 1). This message MUST be issued by the first party, either terminating or originating, to detect 
call termination as indicated below. 

The CMS MUST timestamp this message immediately upon receipt of: 

an NCS-signalling NTFY message indicating on-hook at the calling party MTA (see note 2); or 

on expiration of the destination MTAs call-continuation timer 
The MGC MUST timestamp this message immediately upon receipt of: 

an C7 REL message from the PSTN via the SG; or 

an indication from the MG that an operator services trunk has disconnected. 

Table 24: Call_Dlsconnect Event Message 



Attribute Name 


Required or 
Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none. 


Direction indicator 





none. 


Call Termination Cause 


R 


Normal Termination. 



NOTE 1: In the current telephony network, when the called party goes on-hook, a 10-11 second timer is started. If 
the calling party remains off-hook, and the called party goes off-hook again within that time period, the 
call continues. 

NOTE 2: For emergency services calls, the CMS will normally NOT issue this Event Message as the call duration 
is controlled by the emergency services operator. 
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10.14 QoS_Start 

This Event Message indicates the time at which the AN committed bandwidth on the IPCablecom access network. The 
commitment MAY have been done either through a CM message or a RSVP message. 

The AN MUST timestamp this message immediately upon receipt of: 

the first request for bandwidth commitment by the MTA as indicated in a CM or RSVP message. 

Table 25: QoS_Start Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none 


Direction indicator 





none 


QoS_Descriptor 





none 


MTA UDP Portnum 


R 


none 



10.15 QoS_Stop 



This Event Message indicates the time at which the MTA released its bandwidth commitment on the IPCablecom 
access network. The release MAY be done either through a CM message or an RSVP message. 

The AN MUST timestamp this message immediately upon receipt of: 

a release of bandwidth reservation by the MTA as indicated in a CM or RSVP message. 

Table 26: QoS_Stop Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none 


Direction indicator 





none 


QoS Descriptor 





none 


F ID (NOTE) 


R 


none 


NOTE: F ID is a 32 bit flow indicator: it is referred as connection ID in ITU-T Recommendation J.1 12 
annex A and SF ID in annex B. 



10.16 Time_Change 



This event captures an instance of a time change. The Event_Time attribute in the Event Message Header (table 31) 
MUST contain the time at which the clock on the trusted network element was adjusted. 

Table 27: Time_Change Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none 


Time_Adjustment 


R 


none 
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10.17 QoS_Change 



This Event Message indicates the time at which the MTA modified its bandwidth commitment on the IPCablecom 
access network. The change MAY be done either through a CM message or an RSVP message. 

The AN MUST timestamp this message immediately upon receipt of: 

a change in bandwidth reservation by the MTA as indicated in a CM or RSVP message. 

Table 28: QoS Change Event Message 



Attribute Name 


Required or Optional 


Comment 


[Event Message Header] 
(see table 31) 


R 


none 


Direction indicator 





none 


QoS_Descriptor 





none 


MTA UDP Portnum 


R 


none 



10.18 RTP_Connection_Parameters Event Message 

Deferred. 
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1 1 IPCablecom Event message attributes 

This clause describes the IPCablecom attributes that are included in the IPCablecom Event Messages. 

Table 29 shows a mapping of the IPCablecom Event Messages and their associated IPCablecom attributes. Table 30 
contains a detailed description of the IPCablecom attributes. Table 3 1 contains special IPCablecom attributes that MAY 
be added to the RADIUS accounting-response messages to support a request for retransmission of Event Messages. 

Table 29: IPCablecom Attributes Mapped to IPCablecom Event Messages 



EM Attribute ID 


EM Attribute Name 


Event Message ID 






1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


16 


17 


19 





Reserved 






































1 


EM Header 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


c 
-z. 
o 
m 
-n 

-z. 
m 
o 


X 


X 


X 


X 


X 


X 


2 


Undefined 


































3 


MTA_Endpoint_Name 


X 


X 






























4 


Calling Party Number 


X 










X 






















5 


Called Party Number 


X 




X 






X 






X 








X 








6 


Database ID 






X 




























7 


QueryType 






X 




























8 


Undefined 


































9 


Returned Number 






X 




























10 


Undefined 


































11 


Call Termination Cause 












X 
















X 






12 


Undefined 


































13 


Related_Call_Billing_ 
Correlation ID 












X 






















14 


First_Call_Calling_ 
Party Number 












X 






















15 


Second_Call_Calling_ 
Party_Number 












X 






















16 


Charge Number 












X 














X 








17 


Forwarded Number 


















X 
















18 


Service Name 












X 






X 


X 














19 


Undefined 


































20 


Undefined 


































21 


Undefined 


































22 


Location_Routing_ 
Number 


























X 








23 


Carrier_ldentification_ 
Code 


X 




















X 


X 










24 


TrunkGroupJD 


X 




















X 


X 










25 


Routing Number 












X 










X 




X 








26 


MTA UDP Portnum 














X 


















X 


27 


Undefined 


































28 


Undefined 


































29 


Undefined 


































30 


SF ID 
















X 


















31 


Error Description 


































32 


QoS Descriptor 














X 


X 
















X 


33 


Undefined 


































34 


Undefined 


































35 


Undefined 


































36 


Undefined 


































37 


Direction indicator 


X 


X 










X 














X 




X 


38 


Time_Adjustment 


































X 





Table 30 provides a detailed list of the IPCablecom Event Message attributes. A data value of an attribute may be 
represented by a simple data format (one data field) or by a more complex data format (Data Structure). Data Structure 
formats of the appropriate attributes are detailed in table 31 through table 39. It should be noted that Event Message 17 
is not service dependant. 
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Table 30: IPCablecom Event Message attributes 



EM 

Attribute 

ID 


EM Attribute 
Lengtii 


EM Attribute Name 


EM Attribute Value 
Type 


Attribute Data Description 





Reserved 


1 


59 bytes 


EIVI_Header 


Data structure 
see table 31 . 


Common data required on every 
IPCablecom Event IVlessage. 


2 


Undefined 


3 


variable lengtii, 

maximum of 

255 bytes 


MTA_Endpoint_Nam 
e 


ASCII character 
string. 


Physical Port name (aaln/#) as 

defined in the IPCablecom NCS 

Spec TS 101 909-4. 


4 


20 bytes 


Calling_Party_ 
Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the Originating party. In 

the future other numbering plans 

will be addressed. 


5 


20 bytes 


Called_Party_ 
Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the terminating party. In 

the future other numbering plans 

will be addressed. 


6 


Variable 

lengtii, 

maximum of 

255 bytes 


Database_ID 


Right justified, 

space padded 

ASCII character 

string. 


A unique identifier of the 
referenced database. 


7 


2 bytes 


QueryType 


Unsigned integer 


Query type: 

= Reserved 

1 = Toll Free Number Lookup 

2 = LNPNumberLookup. 


8 


Undefined 


9 


20 bytes 


Returned_ Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 
formatted address specifying the 
number resulting from a database 

query. In the future other 
numbering plans will be addressed. 


10 


Undefined 


11 


6 bytes 


Call_Termination_Ca 
use 


Data structure. 
See table 34. 


Termination code Identifier. 


12 


Undefined 


13 


16 bytes 


Related_Call_ 

Billing_ 
Correlation ID 


Data structure. See 
table 32. 


Billing Correlation ID for possible 
use in value added services. 


14 


20 bytes 


First_Call_ 

Calling_Party_ 

Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the calling party. In the 

future other numbering plans will 

be addressed. 


15 


20 bytes 


Second_Call_ 

Calling_Party_ 

Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the calling party. In the 

future other numbering plans will 

be addressed. 


16 


20 bytes 


Charge_Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of billable party. In the 

future other numbering plans will 

be addressed. 


17 


20 Bytes 


Forwarded_ 
Number 


Right justified, 

space padded 

ASCII character 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the Forwarded Number. 

In the future other numbering plans 

will be addressed. 


18 


32 Bytes 


Service_Name 


Right justified, 

space padded 

ASCII character 

string. 


Class Service Name. Allowed 

names are: 

"CalLBIock" 

"Call Forward" 
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EM 

Attribute 

ID 


EM Attribute 
Length! 


EM Attribute Name 


EM Attribute Value 
Type 


Attribute Data Description 










"Call_Waiting" 
"Repeat Call" 
"Return Call". 


19 


Undefined. 


20 


Undefined. 


21 


Undefined. 


22 


20 bytes 


Location_Routing_N 
umber 


Riglit justified, 

space padded 

ASCII cliaracter 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the terminating party. In 

the future other numbering plans 

will be addressed. For LNP uses. 


23 


8 bytes 


Carrier_ 

Identification 

Code 


Riglit justified, 

space padded 

ASCII cliaracter 

string. 


If the operator provides a service 

for a telecommunications operator, 

the Carrier Identification Code 

(CIC) or other identification is 

recorded in this field. 


24 


6 bytes 


TrunkGroupJD 


Data structure. 
See table 36. 


Trunk group identification. 


25 


20 bytes 


RoutingNumber 


Riglit justified, 

space padded 

ASCII cliaracter 

string. 


IPCablecom will use E.I 64 

formatted address specifying the 

number of the terminating party. In 

the future other numbering plans 

will be addressed. 


26 


4 bytes 


IVITA UDP Portnum 


Unsigned integer 


MTA Endpoint UDP Port Number. 


27 


Undefined. 


28 


Undefined. 


29 


Undefined. 


30 


4 bytes 


SFJD 


Unsigned integer 


Flow ID, a 32-bit integer assigned 

by the AN The flow ID is a 

connection ID in the case of ITU-T 

Recommendation J.1 12 

annex A and a SF ID in the case 

of annex B. 


31 


32 bytes 


Error_Description 


Riglit justified, 

space padded 

ASCII cliaracter 

string. 


A user-defined description of the 
error conditions. Refer to table 33. 


32 


Variable; 
IVIin 8 bytes 


QoS_Descriptor 


Data structure. 
See table 37. 


QoS parameters data. 


37 


2 bytes 


Direction_ 
indicator 


Unsigned integer 


Specifies if a device acts on behalf 

of an originating or terminating part 

of the call at the time an Event 

Message is being generated. 

= undefined 

1 = Originating 
2 = Terminating. 


38 


8 bytes 


Time_Adjustment 


Signed integer 


Time adjustment of an element's 

(CMS, AN, MGC's) clock. 

This time is in millisecond, detailing 

the amount of the time change. 
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1 1 .1 RADIUS Accounting-Response Retransmit Request 
Attributes 

All Network Elements MUST store Event Messages until they have received an Acknowledgement (Ack) from an RKS 
that the data was correctly received and stored. Only when an Ack is received is the network element allowed to delete 
these Event Messages. 

In order to guarantee the reliable transfer of the data the RADIUS Client SHOULD implement a user configurable 
RADIUS message Ack interval and the number of times the client needs to retransmit the event or message. The time 
interval should be configurable (suggested: 10 msec to 10 sec), the number of retries should be configurable (suggested 
to 9). The number of retries MAY span multiple RADIUS Servers (RKSs). After exhausting the number of retries the 
Event Message SHOULD be written to an error file. 

1 1 .2 EI\/l_Header Attribute Structure 

Table 3 1 contains a detailed description of the fields in the EM_Header attribute structure. This Event Message Header 
attribute MUST be the first attribute in every IPCablecom Event Message. 

Table 31 : EM Header Attribute Structure 



Field Name 


Semantics 


Value Type 


Length 


Version 
ID 


Identifies version of this structure. 
1 = IPCablecom. 


Unsigned integer 


2 bytes 


Billing 

Correlation 

ID 


Unique identifier for a transaction within a 
network. See following clause. 


Data Structure table 
32. 


1 6 bytes 


Event 

Message 

Type 


Identifies the type of Event Message. 

refer to table 1 2 for a listing of Event 

message types. 


Unsigned integer 


2 bytes 


Element 
Type 


Identifies Type of Originating Element: 

= Reserved 

1 =CMS 

2 = AN 

3 = Media Gateway Controller. 


Unsigned integer 


2 bytes 


Element 
ID 


Unique code indicating the originating 
IPCablecom network. 


Right justified, space 

padded ASCII 

Character String. 


8 bytes 


Sequence Number 


Each network element MUST assign a 

unique and monotonically increasing 

unsigned integer for each Event Message 

sent to a given RKS. This is used by the 

RKS to determine if Event Message are 

missing from a given network element. 


Unsigned integer 


4 bytes 


Event_time 


Event generation time and date. 

Millisecond granularity. 
Format: yyyymmddhhmmss.mmm 


ASCII character 
string. 


1 8 bytes 


Status 


Status indicators. 


See table 33. 


4 bytes 


Priority 


Indicates the importance to assign 

relative to other network traffic. For 

IPCablecom, values for this field will be 

user defined. 


Unsigned integer 


1 byte 


Attribute 
Count 


Indicates the number of attributes that 

follow (or are appended to) this header in 

the current Event Message. 


Unsigned integer 


2 bytes 


Event 
Object 


This is a "place holder" for future 

IPCablecom releases to allow for a 

grouping of services. It may be 

IPCablecom Voice, IPCablecom Video, 

etc. or it could be IPCablecom, CM, etc. It 

MUST have a value of zero for 

IPCablecom. 


Unsigned integer 


1 byte 
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11 .2.1 Billing Correlation ID Attribute Structure 

Table 32 describes the Billing Correlation ID. The RKS, or some other back office application, uses the Billing 
Correlation ID to correlate Event Messages that are generated for a single transaction. It is one of the fields in the Event 
Message Header. The Billing Correlation ID is unique for each Transaction in the network. All Event Messages with 
the same Billing Correlation ID SHOULD be sent to the same primary RKS except in failover circumstances in which 
case the Event Messages MUST be sent to the next RKS on the failover RKS list. 

Table 32: BillingCorrelationJD Description 



Field Name 


Semantics 


Value Type 


LengtIi 


Timestamp 


High-order 32 bits of NTP time reference. 


Unsigned integer 


4 bytes 


ElementJD 


Network wide unique identifier for the 
originating CMS. 


Right justified, space 
padded ASCII 
Character String. 


8 bytes 


Event Counter 


Monotonically increasing for each 
Transaction. 


Unsigned integer 


4 bytes 



1 1 .2.2 Status Field Attribute Structure 

The Status field of the Event Message Header is a 32-bit mask. Bit is the low-order bit; the field is treated as a 4 byte 
unsigned integer. Table 33 presents Status Field description. 

Table 33: Status Field Description 



Start Bit 


Semantics 


Bit Count 





Error Indicator: 

= No Error 

1 = Possible Error 

2 = Known Error 

3 = Reserved 
(see note) 


2 


2 


Event Origin: 

= Trusted Element 

1 = Untrusted Element 


1 


3 


Event Message Proxied: 

= Not proxied, all data known by sending 
element 

1 = proxied, data sent by a trusted element on 
behalf of an untrusted element 


1 


4 


Reserved. IPCablecom value MUST be 


28 


NOTE: If Known error, then attribute 31 IVIUST be included in the Event IVIessage 

corresponding to this header. If Possible error, then attribute 31 MAY be included in 
the Event Message corresponding to this header. 
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1 1 .3 Call Termination Cause Attribute Structure 

Table 34 describes data structure of the Call_Termination_Cause attribute. 

Table 34: Call Termination Cause Data Structure 



Field Name 


Semantics 


Value Type 


Lengtii 


Source_Document 


Identifies tlie source Document of tine 
Cause Codes: 

= Reserved 

1 = BAF (Bellcore Generic 
Requirements 11 00 CORE). Automatic 
Message Accounting Format 

2 = Future. 


Unsigned integer 


2 bytes 


Cause_Code 


Cause Code Identifier. Meaning 
determined by Source_Document 
defined in previous field. 


Unsigned integer 


4 bytes 



1 1 .4 Trunk Group ID Attribute Structure 

Table 35 describes Trunk Group ID Data Structure. 

Table 35: Trunk Group ID Data Structure 



Field Name 


Semantics 


Value Type 


LengtIi 


TrunkType 


1 = Not Used 

2 = Not Used 

3 = C7 direct trunk group number 

4 = C7 from IC to AT and C7 from AT 
toEO 

5 = Not Used 

6 = C7 from IC to AT and non-C7 from 
AT to EO (terminating only) 

9 = Signalling type not specified. 


Unsigned integer 


2 bytes 


TrunkNumber 


ASCII Identifier. Values in the range 
0000-9999. 


Right justified, space 
padded ASCII 
character string. 


4 bytes 



1 1 .5 QoS Descriptor Attribute Structure 

Table 36 describes QoS Descriptor Data Structure. 

Table 36: QoS Descriptor Data Structure 



Field Name 


Semantics 


Value Type 


LengtIi 


Status_Bitmask 


Bitmask describing structure contents 
(see table 37). 


Bit map 


4 bytes 


Service_Class_ Name 


Service profile name. 


Right justified, space 
padded ASCII 
character string. 


4 bytes 


QoS_Parameter_ Array 


QoS Parameters. Contents 
determined by Status Bitmask. 


Unsigned integer 
array. 


Variable length array 
of 32-bit unsigned 
integers. 
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Table 37 describes the QoS Status Bitmask field of the QoS Descriptor attribute. Bits 2 to 17 describe the contents of 
the QoS_Parameter_Array. Each of these bits indicates the presence (bit = 1 ) or absence (bit = 0) of the named QoS 
parameter in the array. The location of a particular QoS parameter in the array matches the order in which that 
parameter's bit is encountered in the bitmask, starting from bit 2. 

Each QoS parameter present in the QoS_Parameter_Array must occupy four bytes. The definition and encoding of the 
QoS parameters can be found in ITU-T Recommendation J. 112. QoS parameters whose definition specifies less than 
four bytes must be right justified (were the 4 bytes to be treated as an unsigned integer) in the four bytes allocated for 
the array element. 

Table 37: QoS Bit Mask for J. 11 2 annex A 



Start Bit 


Semantics 


Bit Count 




State Indication 

= Illegal Value 

1 = Resource Reserved but not activated 

2 = Resource Activated 

3 = Resource reserved and activated. 


2 


2 


Max packet size 




3 


Average bit rate 




4 


Jitter window 




5 


Frame length 




6 


Requested bandwidth 




7 


Maximum distance between slots 





Table 38: QoS Bit Mask for J.1 12 annex B 



Start Bit 


Semantics 


Bit Count 





State Indication: 

= Illegal Value 

1 = Resource Reserved but not Activated 

2 = Resource Activated 

3 = Resource Reserved & Activated 


2 


2 


Service Flow Scheduling Type 




3 


Nominal Grant Interval 




4 


Tolerated Grant Jitter 




5 


Grants Per Interval 




6 


Unsolicited Grant Size 




7 


Traffic Priority 




8 


Maximum Sustained Rate 




9 


Sustained Traffic Rate 




10 


Maximum Traffic Burst 




11 


Minimum Reserved Traffic Rate 




12 


Maximum Concatenated Burst 




13 


Request/Transmission Policy 




14 


Nominal Polling Interval 




15 


Tolerated Poll Jitter 




16 


IP Type of Service Override 




17 


Maximum Downstream Latency 
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12 Transport Independent Event Message Attribute TLV 
Format 

Every Event Message Attribute is defined by a Type Length Value (TLV) tuple. An attribute TLV tuple has the 
following format: 

Table 39: Event Message Attribute TLV-tuple format 



Field Name 


Semantics 


Fieid Lengtii 


Attribute Type 


IPCablecom Attribute Type (refer 
to table 30). 


4 bytes 


Attribute Lengtii 


IPCablecom Attribute Length (refer 
to table 30) + 5. 


1 byte 


Attribute Value 


IPCablecom Attribute Value. 


Attribute Length bytes 



13 IPCablecom Event Message File Format 

The IPCablecom Event Message File Format has the following basic structure. 

13.1 File Header 

The following header MUST be written at the start of a file formatted using the IPCablecom Event Message File 
Format: 

Table 39A 



Field Name 


Semantics 


Length 


Type 


Format Version 


Version number of file format 


4 bytes 


Unsigned int 


EM Count 


Number of EMs in File 


8 bytes 


Unsigned int 


File Creation Timestamp 


YYYYMMDDHHMMSS.MMM 


18 bytes 


ASCII 


File Sequence Number 


Monotonically increasing 


8 bytes 


Unsigned int 


Model D 


Unique identifier of generating element 


8 bytes 


ASCII 


File Completion Timestamp 


YYYYMMDDHHMMSS.MMM 


18 bytes 


ASCII 



NOTE: There is no checksum included in the file header. It is assumed that the transport mechanism is 

responsible for delivery of damage free files. For example, both of the IP transport protocols, UDP and 
TCP, contain a checksum to protect against damaged messages. 



13.2 File Naming Convention 



Files created using the IPCablecom Event Message File Format MUST use the following naming convention: "PKT- 
EM-yyyymmmddhhmmss-pri-nodeid-seq.bin". 
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1 3.2.1 PKT-EM-yyyymmmddhhmmss-pri-nodeid-seq.bin 

The following table describes each of the components of the filename. 

Table 39B 



Component 


Semantics 


Type 


Length 


File ID 


Identifies this file as 

containing IPCablecom 

Event Messages. 


Literal string "PKT-EM" 


6 characters 


Timestamp 


Time at which file was 

opened by the network 

element. 


yyyymmddhhmmss 


1 4 characters 


Priority 


Priority of this file. 


Integer in the range 1-4 


1 character 


Nodeld 


Uniquely identifies the 

IPCablecom Network 

Element from which this 

file originated. 


ASCII String 


8 bytes 


Sequence number 


Monotonically increasing 
sequence number. 


Integer in the range 000001- 
999999. Zero filled. 


6 characters. 



Each of the filename components is separated by a hyphen "-" character. 

13.3 Configuration Items 

The following items MUST be configurable by the IPCablecom network element creating the file. 

Table 39C 



Name 


Semantics 


Type 


Lengtii 


Maximum File Length 


Maximum size of file, in 

bytes, to which flat file 

can grow before being 

closed for transport. 


Unsigned integer 


4 octets 


Maximum Open Time 


Maximum amount of time, 

in seconds, before file 

must be closed for 

transport. 


Unsigned integer 


4 octets 



The IPCablecom Network Element that created the file MUST close any currently open flat file at the first occurrence 
of either of the following events: 

The file size exceeds the Max File Length. 

The file open duration exceeds the Maximum Open Time. 



14 Transport Protocol 
14.1 RADIUS 

This clause describes how RADIUS is used as a transport protocol between the IPCablecom network elements that 
generate Event Messages (CMS, AN, MGC) and the Record Keeping Server (RKS). The required transport protocol for 
IPCablecom is RADIUS Accounting (RFC 2139) with IPCablecom extensions and MUST be used to transport Event 
Messages from IPCablecom network elements to the RKS. 
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14.1.1 IPCablecom Transport Requirements 

The Event Message transactions MUST be authenticated. 

The transport protocol MAY support confidentiahty of Event Messages. 

End-to-end security across multiple administrative domains is not required. 

14.1.2 RADIUS Accounting Protocol 

The RADIUS Accounting protocol is a client/server protocol that consists of two message types: Accounting-Request 
and Accounting-Response. IPCablecom network elements that generate Event Messages are RADIUS clients that send 
Accounting-Request messages to the RKS. The RKS is a RADIUS server that sends Accounting-Response messages 
back to the IPCablecom network elements indicating that it has successfully received and stored the Event Message. 

The Event Messages are formatted as RADIUS Accounting-Request and Accounting-Response packets as specified in 
RFC 2139. Although IPCablecom specifies RADIUS as the transport protocol, alternate transport protocols MAY be 
supported in future IPCablecom releases. 



14.1.2.1 



Reliability 



The RADIUS messages are transported over UDP, which does not guarantee reliable delivery of messages, hence the 
request/response nature of the protocol (see RFC 2138 for the technical justification of choosing UDP over TCP for the 
transport of Authentication, Authorization and Accounting messages). 

When an RKS receives and successfully records all IPCablecom Event Messages in a RADIUS Accounting-Request 
message, it MUST send an Accounting-Response message to the client. If the IPCablecom network element does not 
receive an Accounting-Response within the configured retry interval, it MUST resend the same Accounting-Request 
either to the same RKS or the next RKS on its failover list. The IPCablecom network element SHOULD continue 
resending the Accounting-Request until it receives an acknowledgement from an RKS or the message expires from its 
cache. The RADIUS server MUST NOT transmit any Accounting-Response reply if it fails to successfully record the 
Event Message. 



14.1.2.2 



Authentication and Confidentiality 



Refer to TS 101 909-1 1 for details concerning the use of IPSec to provide both authentication and confidentiality of the 
RADIUS messages. 

Each IPCablecom network element generating Event Messages MUST use a shared secret hard coded to the value of 16 
ASCII Os, i.e. the shared secret is "0000000000000000" to calculate the Authenticator field in the RADIUS message 
header. In order to improve interoperability with existing RADIUS server implementations, the RADIUS clients and 
servers MUST still calculate and populate the Authenticator field as described in RFC 2139. 

1 4.1 .2.3 Standard RADIUS Attributes 

Each RADIUS message starts with the standard RADIUS header shown in table 40. 

Table 40: RADIUS Message Header 



Field Name 


Semantics 


Field Length 


Code 


Accounting-Request = 4 
Accounting-Response = 5 


1 byte 


Identifier 


Used to matcln accounting-request and accounting-response 
messages. 


1 byte 


Lengtii 


Total lengtli of RADIUS message. 
IVIin. value = 20, max value = 4 096. 


2 bytes 


Autlienticator 


Accounting-Request: MD5 checksum with null shared secret 

calculated per RFC 2139. 

Accounting-Response: MD5 Response Authenticator with null 

shared secret calculated per RFC 2139. 


16 bytes 
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The standard RADIUS Acct_Status_Type attribute MUST follow the RADIUS Message Header in every 
Accounting-Request message. This attribute indicates the type of this RADIUS Accounting-Request and is specific to 
the use of RADIUS as the transport protocol. An Acct-Status-Type value of Interim-Update is used to represent 
IPCablecom Event Messages. This improves interoperability with existing RADIUS server implementation. 

Table 41 : RADIUS Acct_Status_Type 



Type 


Length 


Value 


40 


6 bytes 


Interim-Update = 3 



The Acct_Status_Type attribute is the only standard RADIUS attribute used by IPCablecom. IPCablecom attributes are 
defined in clause 1 1 of the present document. IPCablecom attributes are encoded in the RADIUS Vendor Specific 
Attributes (VSA) structure as described in table 42. Additional IPCablecom or VSAs can be added to existing Event 
Messages by adding additional RADIUS VSAs to the message. 

The VSA includes a field to identify the vendor and the Internet Assigned Number Authority (lANA) has assigned 
IPCablecom an SMI Network Management Private Enterprise Number of 4 491 for the encoding of these attributes. The 
RKS server SHOULD ignore Event Messages where the IPCablecom "Event Message type" is unidentified. The RKS 
server SHOULD also ignore IPCablecom event attributes where the event attribute type is unidentified. 

Table 42: Radius VSA Structure for IPCablecom Attributes 



Field Name 


Semantics 


Field Lengthi 


Type 


Vendor Specific = 26. 


1 byte 


Length 


Total Attribute Length 
(see note). 


1 byte 


Vendor ID 


CableLabs = 4 491 . 


4 bytes 


Vendor Attribute Type 


IPCablecom Attribute Type (refer to 
table 34). 


4 bytes 


Vendor Attribute Lengtii 


IPCablecom Attribute Length (refer 
to table 34). 


1 byte 


Vendor Attribute Value 


IPCablecom Attribute Value. 


Vendor Length bytes 


NOTE: Value is Vendor Length 


+ 8. 





14.1.3 IPCablecom Extensions 

14.1.3.1 IPCablecom RADIUS Accounting-Request Packet Syntax 

<RADIUS Accounting-Request> : : == 
<RADIUS message Header> 
<RADIUS Acct-Status-Type Attribute> 
<IP Cablecom EM List> 

<IP Cablecom EM List> : : == 

<IP Cablecom EM> | 

<IP Cablecom EM List> <IP Cablecom EM> 

<IP Cablecom EM> : : == 

<RADIUS VSA for IP Cablecom EM Header Attribute> 

<IP Cablecom EM Attribute List> 

<IP Cablecom EM Attribute List> : : == 

<RADIUS VSA for IP Cablecom EM Attribute> 

<IP Cablecom EM Attribute List> <RADIUS VSA for IP Cablecom EM Attribute> 
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The potential of a high Event Message volume raised the concern that the RADIUS mechanism for ensuring reliability 
via request/response may consume too much bandwidth or be too computationally intensive. This led to the requirement 
that it be possible to transit multiple IPCablecom Event Messages in a single RADIUS message. The use of this "batch 
mode" is left to the discretion of the IPCablecom network element and will likely depend on the latency requirements of 
the particular event type. The number of Event Messages encapsulated in a single RADIUS message is still subject to 
the maximum RADIUS message length restriction of 4 096 bytes. 

The Event Message Header MUST be the first attribute within a given Event Message. If multiple Event Messages are 
sent in a single RADIUS Accounting-Request, the Event Message Header attribute indicates the start of a new Event 
Message. The order of the Event Message attributes which follow the Event Message Header is arbitrary. 

IPCablecom extends RADIUS Accounting, by introducing new attributes and new values for existing attributes. Since 
the RADIUS protocol is extendable in this manner, it is expected that existing RADIUS server implementations will 
require minimal modifications to support the batch collection of IPCablecom Event Messages. 

The only mandatory attribute in a RADIUS Accounting-Request message is the Acct-Status-Type, which typically 
indicates whether the Accounting-Request marks the beginning of the user service (Start) or the end (Stop). Since a 
IPCablecom Accounting-Request message may contain multiple Event Message Packets, a single message may contain 
Event Messages, which mark both the beginning and end of the user service. For this reason, an 
Acct-Status-Type value of Interim-Update is used to represent IPCablecom Event Messages. This improves 
interoperability with existing RADIUS server implementation. 

14.1 .3.2 Retransmission Using RADIUS Accounting-Response Packet Syntax 

Due to the presence of the sequence number in the Event Message Header, it is possible for the RKS to detect missing 
Event Messages. The RKS MAY request retransmission of these Event Messages by including additional IPCablecom 
Event Message attributes in an Accounting-Response. Refer to table 32 for a description of these attributes. 

<RADIUS Accounting-Response> : == 

<RADIUS message Header> 

<RADIUS VSA for IP Cablecom Missing_Event_Time_Start attribute> 

<RADIUS VSA for IP Cablecom Missing_Event_Time_Stop attribute> 

<RADIUS Accounting-Response> : == 

<RADIUS message Header> 

<RADIUS VSA for IP Cablecom Missing_Event_Sequence_Start attribute> 

<RADIUS VSA for IP Cablecom Missing_Event_Sequence_Stop attribute> 

Two mechanisms for retransmission request SHOULD be supported by the IPCablecom network elements and the 
RKS: 

Time based: Refer to table 32 for a detailed description of the IPCablecom Event Message time-based 
retransmission attributes: Missing_Event_Start_Time and Missing_Event_Stop_Time. 

Sequence number based: Refer to table 1 for a detailed description of the IPCablecom Event Message sequence- 
based retransmission attributes: Missing_Event_Start_Sequence and Missing_Event_Stop_Sequence. 

The IPCablecom network element behaviour on receipt of a retransmission request for Event Messages, which 
are still in its cache depends on whether the requested Event Messages have already been acknowledged by an 
RKS and if so, the RKS that acknowledged them. 

If the IPCablecom network element still has the requested events in its event cache and has not received 
confirmation from any RKS that the events have been successfully recorded, it MUST send the Event Messages 
to the requesting RKS. 

If the IPCablecom network element still has the requested events in its event cache but has already received 
confirmation that the events have been successfully recorded from the RKS requesting the retransmission, it 
SHOULD send the Event Messages to the requesting RKS. 

If the IPCablecom network element still has the requested events in its event cache but has already received 
confirmation fi^om an RKS other than the one requesting the retransmission that the events have been 
successfully recorded, it SHOULD send the Event Messages to the requesting RKS. 
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1 4.2 File Transport Protocol (FTP) 



The File Transfer Protocol (FTP) MAY be used to transport Event Messages from IPCablecom network elements to the 
RKS. If this transport protocol is used, the RKS hosts an FTP server to accept files transferred by the IPCablecom 
network element. The IPCablecom network element acts as the FTP client, pushing the files to the RKS for processing. 

If FTP is used as a transport protocol, then the file MUST be formatted using the IPCablecom Event Message File 
Format. 

14.2.1 Required FTP Server Capabilities 

The FTP server at the RKS MUST have the following capabilities: 
- PASV Mode; 

Authentication support; 
File Transfer logging. 
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